The general architecture of service access providers is shown in FIG. 1. Data traffic between an end-user (not shown) and the internet 30 or any other data network (PDN) passes a service network 10, where the data traffic is processed by one or several service providing modules. Access networks 51, 52, 53 such as 2G/3G, LTE and fixed line access networks are connected to a gateway 40. Depending on the access type, this can be a BNG (Border Network Gateway), GGSN (Gateway GPRS Support Node) or a PGW (Packet Gateway). At an activation of a data packet flow, the gateway provides end-users with an IP address. It handles authentication, accounting and charging and it may perform additional tasks like acting as PCEF (Policy and Charging Enforcement Function) in 3GPP networks. The gateway 40 is the entry point to the service network which refers in this application to an operator controlled network with one or multiple modules attached providing services that add value to the operator or to the end-user. Examples of said services are firewalls, HTTP header enrichment or content filtering modules.
As shown in FIG. 1, the operator's demarcation towards the internet is a point of interconnect 20 (PoI), since the IP address allocated to the end-user is typically a private IP address, a network address translation 21 (NAT) to a public IP address is usually performed close to the PoI 20.
With current technologies, the allocation value added services in service networks is inflexible. Processing end-user data traffic or data flows based on their type, source or destination by selected services is only possible to a limited extent at the cost of complex network and service configurations.
Telecommunication networks often include a number of Transparent Value Added Services (TVAS), also named service providing modules, which transparently process traffic traversing them. In the logical network architecture as shown in FIG. 1 TVAS are connected and belong logically to the Service Network.
With “classical” service network, a network composed of transport infrastructure and hardware appliances implementing the services, is meant, where the main purpose of the majority of the hardware components used is to support the execution of the services and the steering of the traffic through them.
The term “transparent” is used in this case to refer to traffic processing functions which are not explicitly addressed by the traffic itself in any way, and that are under the sole control of the telecommunications provider. This is opposed to functions like DNS (Domain Name Server)-steered CDN (Content Delivery Network) servers, configurable HTTP proxies or services implemented by IMS (IP Multimedia Subsystem) and explicitly addressed via SIP (Session Initiating Protocol). So “transparent” means that a user requesting a data packet flow is not aware of the provided service and does not directly address the service.
It shall be noted that the terms “value added service” is to be given a very broad interpretation including real and potential added value which may be value for the end-user, value for the network provider, or potentially for other parties.
Examples of services provided by TVAS could be:                Firewalls        Spam filters/Antivirus        Content Filtering        Parental Control        Transparent Internet Caches        HTTP Header enrichment        Deep Packet Inspection        
The main reason for the distinction of TVAS versus non-transparent VAS is that the transport network plays a central role in the usage of TVAS as it is the only entity able to direct traffic to one TVAS or node. The communication endpoints can, by definition of “transparent”, not steer the usage of a TVAS. In the same way, most existing TVAS do not implement any awareness of other potential TVAS or chaining among them and can therefore not steer traffic to another TVAS.
At the same time, the need for TVAS to be deployed in legacy networks has resulted in strong dependencies between the service implementation itself and the transport network, with current TVAS products often being based on networking appliance platforms or making use of such. Examples of these dependencies are:                TVAS on high throughput routing/switching platforms due to the need for all traffic to traverse them despite of only a fraction of it being really processed        Need for high-availability comparable to transport equipment even though the service itself does not require such high-availability. It shall be ensured that traffic sent via a TVAS is not dropped due to a TVAS failure.        Integrated NAT/NAPT (Network Address and Port Translation) functionality to steer return traffic back to the same function        Strong integration with load balancing functions in cases where stateful TVAS functions require smart load balancing to the right instance. This may result in TVAS product including both load balancers as component, or creating limitations like maximum number of instances or strict connectivity requirement between load balancers and TVAS servers        
One approach to steer traffic through a chain of TVAS or service providing modules is to control the uplink and downlink traffic using software-defined network technologies without NAPT (Network Address and Port Translation).
As shown in FIG. 2, the idea is to control the TVAS 81, 82 chain by a central controller 70. As shown in FIG. 2, all TVASs 81, 82, the gateway 40 and the PoI 20 are connected to an OpenFlow network. The controller 70 provides paths through the OpenFlow network for every data flow, identified by its five-tuple (source IP address, destination IP address, source port, destination port and protocol number). The OpenFlow switches 61, 62, 63 base the forwarding decision mainly on matching the five-tuple information with entries in their flow tables. If no match is found, the packet is forwarded to the controller 70 for analysis. In turn the controller configures a bidirectional path through the OpenFlow network 60. By that traffic steering in the Service Network can be achieved on a per data flow base.
There is a clear trend in the industry to move services and applications from dedicated hardware appliances to virtualized environments in data centers. Vendors of virtually all types of software centric products, and in particular of TVAS, are requested in RFx:s (Request for [Information, Proposal, Quotation, Bid]) to provide their products as virtual appliances.
While there are some TVAS which are very data plane processing intensive, which may incur significant performance degradation if deployed as virtual appliances, there are others which are very likely to be extensively deployed as such in the near future. Even for those being very data plane processing intensive, it is likely that they will also be eventually virtualized, if not to typical data-center COTS (Components Off The Shelf) hardware, at least to yet-to-come hardware architectures designed to support the efficient virtualization of exactly such kind of applications and services.
It is expected that the virtualization of TVAS will have a direct impact on how service chaining is implemented. The following factors can have decisive impacts:                Virtual TVAS (vTVAS) will be deployable/instantiable on different data center blades and in different “sizes” at a low cost and as decided by an orchestration system. This enables possibilities like:                    Dedicating instances to specific service chains (so that there is no need any more to reclassify traffic coming out of such a TVAS instance)            Choosing the location of the instances so that all TVAS instances for the same chain are collocated, or located close to each other            Creating virtual network topologies linking those TVAS instances so that legacy routing/forwarding mechanism can handle the traffic steering                        The process of virtualizing legacy services and applications will require some software development, and while doing this, it is expected that the virtualized versions of legacy bare-metal TVAS can get additional functionality, like:                    Preservation of VLAN tags from ingress to egress            Variability in the “size” (characteristics, admissible load) of the instances with direct dependency to computing resources like CPU performance and memory capacity            Providing feedback/information about current load in order to enable automatic scaling out and in by adding or removing instances to adapt to varying capacity needs.                        
According to the Network Function Virtualization (NFV) initiative (“Network Functions Virtualization, An Introduction, Benefits, Enablers, Challenges and Call for Action”, SDN and OpenFlow SDN and OpenFlow World Congress, October 2012), even the entity demarcating the ingress into service chaining (typically the GGSN or PGW in mobile networks and the BNG in fixed networks) may move into data centers as virtualized appliances.
The SDN based traffic steering methods used for legacy TVAS are very powerful, but also complex and costly due to their demands on the SDN-controlled data-plane devices, on the SDN controller and on the source NAPT devices. Scalability and the doubts about the ability to handle high bandwidth at wire line speed are also a problem.
The virtualization of TVAS thus bring the potential of high efficiency simplification improvement which are not leveraged by current SDN based solution. Approaches to simplify service chain by leveraging TVAS changes related to the upcoming virtualization process or applicable to fully new virtual TVAS products are very conservative and restricted to add modifications like the preservation of VLAN tags, or more generic tags or labels, in order to facilitate the usage or to improve the efficiency of legacy traffic steering methods.
In the case of just leveraging the preservation of tags, the resulting SDN based methods get a quantitative improvement by reducing the needs for service respecification after each virtual TVAS, but they share the architecture complexity and a significant part of the costs discussed above.
Approaches based on creating dedicated instances for every single chain and using cloud orchestration to both create a virtual topology enforcing the traffic steering and to get the traffic flows to efficiently use the underlying physical topology imply a high number of disadvantages and trade-offs which are likely to result in inefficient use of processing power and in complexity. Examples of such disadvantages and trade-offs are:                Different TVAS, due the nature of the service they implement, may present huge differences in the amount of flows that can be handled per unit of computing power or memory capacity. vTVAS instantiation per chain may result in extremely underutilized vTVAS instances        Some TVAS require cooperation/synchronization among instances to achieve their goals (example: transparent caches, content delivery networks, botnet-attack detection). A high number of underdimensioned vTVAS can result in high inefficiencies.        If there is a need to include a non-virtualized TVAS (as mentioned above, for very data-plane intensive services, their virtualization may come much later than for others or maybe never), a dedicated hardware appliance for each chain would be needed, or the method would have to get combined with one of the legacy methods described above and inherit all its disadvantages.        
Although not explicitly described in previous paragraphs, it would also be possible to implement inside the TVAS awareness about service chaining and about neighbor TVAS including their number (different TVAS and different instances) and their addresses, so that they can explicitly send traffic to the next TVAS in the chain and react to additions, removals or other changes in the service chains. While possible, the degree of complexity would be quite high and it is very unlikely that it would ever be successfully implemented in a multivendor manner.
Accordingly a need exists to avoid at least some of the above-mentioned drawbacks when a data packet flow is passed through a chain of services and to provide a possibility to effectively control the passing of data flows through a chain of services.